Read more of this story at Slashdot.
Read more of this story at Slashdot.
The Trump administration is quietly considering a rule change that could make it easier for polluters to build facilities—including certain gas plants and diesel generators that power data centers—with little to no notice to the public.
On Wednesday, the Environmental Protection Agency held a public hearing on a proposed rule change that would hand the power to states to decide how the public participates in the permitting process for certain new sources of air pollution. The proposed rollback comes as data centers face greater pushbackacross the US, with many communities using the permitting process to try to slow down development. Any changes could have major consequences for how ordinary people are given notice about new or expanded polluting facilities coming into their neighborhoods.
“As someone actively working in communities with data centers, I know this to be fundamentally true: People want to have a say,” Vanessa Lynch, a Pennsylvania organizer with Moms Clean Air Force, said at the EPA hearing.
Companies building any kind of facilities that release air pollution are required to get permits under the Clean Air Act. Polluting sources can either be put through a “major” permitting process, meaning that they meet or exceed thresholds for certain pollutants, or a “minor” one for those that don’t.
Major sources of pollution are reviewed by both federal and state regulators and have extensive requirements before and after construction. However, there’s less oversight of minor sources. The scope of what gets permitted as a minor source is extremely broad and can include everything from dry cleaners and auto body shops to to diesel and gas engines. The latter two are increasingly being used to power data centers, with operators such as xAI and Meta using minor source permitting processes to build behind-the-meter gas plants.
The Clean Air Act does require the public to be involved in permitting processes; Congress has specified that major sources need to have several public steps, including a public hearing. EPA rules require some public participation for minor source permits. But thanks to a patchwork of state enforcement laws, that engagement process—and whether state agencies are actually complying with EPA requirements—varies across the US.
If the proposed rule is finalized, “it would put state and local agencies most familiar with local issues in the driver’s seat to determine whether, when, and for how long to provide opportunities for public participation for proposed new minor sources and modifications,” an EPA spokesperson tells WIRED, noting the rule wouldn't alter emissions standards.
These state-by-state differences can make a big difference in how the public gets involved. Keri Powell, an Atlanta-based attorney at the environmental legal advocacy group Southern Environmental Law Center, says that groups like hers often end up taking on cases in states like Georgia, which, she says, has a more robust public notification and participation process for minor sources. Earlier this month, the group alerted the state utility about construction issues at a data center, based on information they’d gotten from the companies’ public air permit applications. But if the EPA removes the federal requirement, community and legal groups in the state could get little to no heads up about upcoming projects and be shut out of participation and review.
“Georgia is an example of a place where I can say I’m concerned,” Powell says.
Sara Lips, the director of communications at Georgia’s Environmental Protection Division, says that the agency is “determining whether proposed federal rule changes would affect the public participation requirements per the state regulations.”
Kentucky also has stronger public participation laws for minor source permits. Byron Gary, a senior attorney at the Kentucky Resources Council, says state agencies have made an “informal commitment” behind the scenes to keep their public participation rules the same, even if the EPA changes its rules. But, he says, that could shift: “Who knows [if] the next administration, whether they would actually change it.”
Texas is an example of what lower levels of engagement look like. The data center boom there has driven a massive buildout of private gas plants, many of which rely on minor pollution permits. The state’s lower levels of enforcement have left some communities living in the shadows of data centers surprised at the scope of fossil fuel infrastructure being installed near their homes.
Since coming into power, the Trump administration has gone all in on artificial intelligence, removing multiple roadblocks for data center development at the federal level. That includes efforts at the EPA, which is working to make the US “the AI capital of the world,” the agency spokesperson says.
Companies are also spending vast sums of money on the data center buildout: Spending on data center construction outpaced spending on public transportation infrastructure for the first time in June. Given that public opposition is creating a new bottleneck for data center development, the timing of the rule revision, Powell says, is probably not an accident.
“I think it's part of a package of rules that the Trump administration is pushing through to make it easier for AI data centers to be constructed,” she says.
This story originally appeared on wired.com.

LG is reportedly pulling a McAfee pop-up ad from a controversial app that some of its monitors have stealthily installed on connected computers.
An example of the pop-up ad is seen in a still from Gamers Nexus' video.
Credit:
Gamers Nexus/Windows/YouTube
The app, LG Monitor App Installer, installs itself through a Windows Update alongside monitor driver updates. LG Monitor App Installer then pushes ads for a 30-day free trial for McAfee, as well as other software, via a pop-up on affected systems, multiple users have reported.
This has drawn negative attention recently, with complaints surfacing on Reddit and a subsequent video from YouTube channel Gamers Nexus. In the video, editor-in-chief Steve Burke said that the publication paid $1,200 for an LG UltraGear 3GX900A-B gaming monitor (the monitor’s price dropped to $600 two days later, Burke said) for testing and replicated the behavior “several times” across “multiple” Windows 11 systems.
After LG Monitor App Installer was installed, a pop-up appeared on the screen’s lower-right corner “on every single boot,” Burke said. Most of the time, the pop-up was a McAfee ad. The publication also reported seeing ads for LG Switch, LG Calibration Studio, LG Dual Controller, and LG Channels on rare occasions.
Following Gamers Nexus’ video, a Microsoft representative stated that the LG Monitor App Installer will no longer show pop-up ads for McAfee. In response to a social media post about the app, Pavan Davuluri, EVP of Windows and devices at Microsoft, said this week:
We’ve connected with the team at LG and as an immediate next step, they have agreed to disable the McAfee pop-up from their app. We appreciate LG working with us toward a shared goal of a better experience for our mutual customers. We will keep improving here with our ecosystem partners.
As mentioned, some LG monitors appear to have been installing LG Monitor App Installer onto Windows computers for months. Publication Windows Latest noted that the app recently got an update, “and its changelog mentions McAfee as an additional app,” which could be what prompted more people to see the ads…and then complain about them.
However, the removal of McAfee doesn’t address the problem of a peripheral installing ad-pushing software onto people’s computers.
Users have been finding LG Monitor App Installer and its ads on their systems without LG ever showing a prompt or asking for permission. LG has some of the most expensive computer monitors available. Paying, in some cases, over $1,000 for a monitor that ends up forcing ads onto Windows is disruptive and a privacy concern. Once the app is installed, “LG technically possesses permission to use ‘all system resources,’” as well as to “collect geolocation, device data, online activity, contacts, user credentials, transactions, and more,” Burke said.
Gamers Nexus shared this screenshot showing LG's app installing via Windows Update.
Credit:
Gamers Nexus/Windows/YouTube
It’s also concerning that the practice has been going on for years and has seemingly expanded recently. Burke said he recently started seeing the pop-up ad on LG monitors he purchased three years ago.
The incident also brings questions about what Windows permits from peripherals’ companion apps.
LG Monitor App Installer's description on the Microsoft Store states that the app is for users to “easily install and use apps supported by your monitor through LG Monitor App Installer” and lists McAfee as one of those apps.
Further, Microsoft allows Universal Windows Platform device apps “to automatically install when the user connects their device to the PC” if the user hasn’t opted out of Recommended Settings during installation and is connected to the Internet and signed into the Microsoft Store, per a Microsoft support page for Windows developers spotted by Windows Latest. The page reads:
The automatic installation feature does not provide a notification to the user when the app is installed. Some users may find this experience confusing and frustrating and give your app a bad rating.
Other hardware vendors have been criticized for their devices automatically installing unwanted software when connected to a computer. Examples include Razer (gaming peripherals), Logitech (gaming and productivity peripherals), Asus (motherboards), and Gigabyte (motherboards). Considering that most monitors don’t necessarily require a companion app and can be rather expensive, the forcible installation of LG Monitor App Installer may seem particularly egregious.
Ars Technica reached out to LG about the purpose of LG Monitor App Installer, affected monitors, and privacy concerns. A company representative acknowledged receipt of the questions but didn’t provide a response ahead of publication.
Citing user complaints, Gamers Nexus listed the following monitors as auto-installing LG Monitor App Installer onto PCs. But with Microsoft approving of the practice, there may be more monitors installing LG’s bloatware:
Every developer has experienced it.
A test passes perfectly on your machine.
It passes again in your local build.
You push your changes.
Minutes later, the CI pipeline fails.
You rerun it.
Now it passes.
Nothing changed.
Welcome to the world of flaky tests.
Flaky tests are one of the biggest productivity killers in modern software development. They waste engineering time, reduce confidence in continuous integration, and eventually train developers to ignore failing builds.
While flaky tests can have many causes, one of the most common is surprisingly simple:
Hidden external dependencies.
Learn about Unit Testing Best Practices
The word unit has an important meaning.
A unit test should verify one unit of behavior in complete isolation.
If a test depends on something outside that unit, it becomes harder to reproduce, harder to maintain, and more likely to fail unexpectedly.
A reliable unit test should behave the same way:
External dependencies make that much harder.
Reading or writing files seems harmless.
Perhaps your test loads a configuration file.
Maybe it writes temporary output.
Or perhaps it reads sample JSON from disk.
The problem isn’t the file itself.
The problem is everything surrounding it.
Questions suddenly appear:
None of these questions relate to the business logic you’re trying to verify.
Your test has stopped testing your code and started testing your environment.
Nothing makes a unit test less predictable than relying on a network.
Even calls to localhost introduce unnecessary risk.
Network-dependent tests can fail because:
The production code may be perfectly correct.
The network simply wasn’t.
Unit tests should never require a network connection unless they are intentionally integration tests.
Windows applications often read configuration from the Registry.
That works perfectly in production.
It usually doesn’t belong in a unit test.
Registry values differ between:
Tests that quietly depend on Registry values become extremely difficult to reproduce.
Time is one of the most overlooked dependencies.
Consider code like this:
if (DateTime.Now.Hour > 18)
It seems innocent.
Until the test suddenly fails tomorrow.
Or next month.
Or during daylight saving time.
Time-based logic should be isolated so tests can control it.
Otherwise your test suite changes behavior simply because the clock moved forward.
Environment variables are another hidden dependency.
Perhaps your code reads:
Those values differ everywhere.
Tests that depend on environment variables often pass on one machine and fail on another.
Random numbers.
GUID generation.
Temporary file names.
Thread scheduling.
These all introduce uncertainty.
A good unit test should produce the same result every single time it executes.
Anything random makes failures harder to reproduce.
Individually, these dependencies seem small.
Together they create enormous maintenance costs.
Developers begin saying things like:
“Just rerun the build.”
“That test always fails.”
“Ignore that warning.”
Those phrases are warning signs.
Once developers stop trusting the test suite, the value of automated testing begins to disappear.
The challenge is that many developers don’t even realize their tests contain these dependencies.
Reading the source code isn’t always enough.
A file access may happen three libraries deep.
A network call may occur through a helper class.
A registry read may happen inside a framework component.
These behaviors only become visible while the test executes.
That’s why runtime analysis is so valuable.
Instead of asking what the code looks like, runtime analysis asks:
What did this test actually do?
It’s important to distinguish between unit tests and integration tests.
Integration tests are expected to communicate with databases, web services, queues, file systems, and other external components.
That’s their purpose.
Unit tests have a different goal.
They should isolate business logic from those dependencies.
The problem isn’t accessing external resources.
The problem is doing so unintentionally inside a unit test.
Reliable unit tests share several characteristics.
They are:
Removing hidden dependencies is one of the most effective ways to achieve those goals.
Developers spend less time investigating failures.
CI pipelines become more reliable.
Refactoring becomes safer.
Confidence increases.
Static analysis can detect many useful issues.
But runtime behavior tells a different story.
By observing tests while they execute, it’s possible to identify hidden dependencies that are invisible from source code alone.
TypeMock Test Review performs this runtime analysis and highlights unexpected behaviors such as:
These insights help development teams identify fragile tests before they become flaky builds.
The best unit tests don’t just pass.
They pass consistently.
They don’t depend on your laptop.
They don’t depend on today’s date.
They don’t depend on network connectivity.
They don’t depend on files that happen to exist.
They validate one piece of behavior in isolation.
As automated test suites continue to grow, identifying hidden dependencies becomes increasingly important.
Because the goal isn’t simply writing more tests.
It’s building tests developers can trust.
TypeMock Test Review, included in the TypeMock Isolator 9.5 , helps identify hidden runtime dependencies that make automated tests fragile, unreliable, and difficult to maintain.
The post Why Unit Tests Should Never Access Files, Networks, or the Registry appeared first on Typemock.
The Cybersecurity and Infrastructure Security Agency (CISA) has issued a postmortem on a recent data leak in which a contractor published dozens of internal CISA credentials — including AWS Govcloud keys — in a public GitHub repository for almost six months before being notified by KrebsOnSecurity. Experts say the gaps identified in the agency’s initial response provide important lessons that all security teams should absorb.

On May 15, 2026, the security firm GitGuardian asked for help in notifying CISA about the existence of a public GitHub repository called “Private CISA” that included 844 MB of sensitive CISA-related data. One of the exposed files, titled “importantAWStokens,” included the administrative credentials to three Amazon AWS GovCloud servers. Another file — “AWS-Workspace-Firefox-Passwords.csv” — listed plaintext usernames and passwords for dozens of internal CISA systems.
CISA quickly acknowledged our initial alert, but took more than 48 hours to invalidate the AWS keys and many other important secrets leaked in the GitHub repo. In its report on the data leak, CISA said the complexities of the agency’s systems and interconnections with federal and industry partners caused its key rotation to take longer than anticipated.
“Drawing on this experience, CISA encourages others to maintain mature and well-tested key management capabilities,” the report notes.
CISA also admitted it can do better when it comes to responding to security incident notifications from external parties. The postmortem stresses that clear and distinct reporting channels are essential to ensure that incidents affecting the organization itself are handled differently from those involving its products or customers.
“In CISA’s case, these channels were not well defined, leading the security researcher to try multiple avenues – including emailing the contractor, submitting through CISA’s vulnerability disclosure platform (which is intended for vulnerabilities impacting the broader cybersecurity community), and ultimately involving a reporter,” reads the analysis written by Preston Werntz and Brad Libbey, the acting chief information officer and acting chief information security officer at CISA, respectively.
CISA said it is refining its reporting channels to make them easier and faster for researchers. “Additionally, while many researchers rely on the security.txt file, organizations can ensure clarity by publishing reporting instructions in multiple prominent locations,” the CISA authors wrote.
Guillaume Valadon, the GitGuardian researcher who first contacted KrebsOnSecurity about the exposed CISA credentials, said CISA ignored nine automated alerts about the exposed credentials prior to our notification on May 15. Valadon’s company constantly scans public code repositories at GitHub and elsewhere for exposed secrets, automatically alerting the offending accounts of any apparent sensitive data exposures.
“Letting nine notification emails go unanswered is how a one-day incident becomes a six-month exposure,” Valadon wrote in an analysis of CISA’s report. “Make it trivial to report a leak about you, not just about your products. The person reporting a leak to you is not the threat. Publish a security.txt, but do not stop there. Put reporting instructions in several prominent places, and make sure a report about your own infrastructure does not land in a product-bug queue.”
The report’s authors also emphasized the importance of continuously scanning public code repositories like GitHub for exposed secrets, and said CISA has since rotated all secrets and created an action plan to improve management of developer secrets and to better monitor for them going forward.
The report notes that while CISA had developed a playbook for responding to cybersecurity incidents, that playbook somehow didn’t include what to do in situations involving GitHub or other cloud services. Valadon said the report validates the need to scan continuously — not just quarterly — for exposed secrets.
“The Private-CISA repository sat public for six months,” Valadon wrote. “Continuous monitoring of public GitHub surfaced it. Comprehensive internal scanning could have caught the plaintext passwords and committed backups long before they left the building.”
CISA gave itself passing grades on several areas of security preparedness that it said helped the agency gauge the scope and impact of the exposed secrets, including enhanced logging capabilities, and the adoption of zero-trust principles in both its production and development systems. CISA said those detailed logs allowed it to show that no customer or mission data was exposed, and that the leaked credentials were not used outside of CISA’s environments. The agency said the contractor who exposed the secrets had their system access revoked.
Valadon reckons the biggest takeaway is the CISA postmortem itself, and praised the agency for being transparent about what worked and what didn’t.
“To my knowledge, it is also the first time a national cybersecurity agency has publicly advocated for secrets scanning and for simplifying relations with security researchers,” Valadon wrote. “That is exactly the incident communication we should expect from every organization.”